Skip to main content

EVPN Part 1: Vì Sao Cần EVPN?

Phần 1/6 trong loạt EVPN — bắt đầu từ đây, chưa cần biết gì về EVPN. Không có cấu hình trong phần này, chỉ có khái niệm và analogy. Đọc xong, phần sau trong loạt bài sẽ nói tiếp về Route Types & Cách Học MAC/IP.

Nếu bạn từng nghe "EVPN" và thấy nó như một mớ chữ viết tắt đáng sợ — MP-BGP, VTEP, VNI, RD, RT, IRB — thì tài liệu này viết cho bạn. Nguyên tắc xuyên suốt cả loạt bài: hiểu khái niệm trước, cấu hình sau. Không một dòng CLI nào xuất hiện ở đây. Lý do rất thực tế: rất nhiều người học EVPN bằng cách copy-paste config mẫu, dán vào thiết bị, nó không chạy, và họ không biết vì sao — vì họ chưa từng hiểu tại sao từng dòng config đó tồn tại. Tài liệu này đi ngược lại: hiểu bản chất trước, để khi bạn nhìn vào một dòng config ở phần sau, bạn biết chính xác nó đang giải quyết vấn đề gì.

Mục lục​

1. Giới thiệu & cách tiếp cận học EVPN​

EVPN là viết tắt của Ethernet VPN — một giao thức control-plane chạy trên nền BGP, dùng để cho các switch trong một data center biết "địa chỉ MAC/IP này đang nằm ở thiết bị nào". Nghe có vẻ đơn giản, nhưng đây chính là mảnh ghép còn thiếu để giải quyết một bài toán rất cụ thể mà Mục 2 sẽ trình bày: làm sao kéo dài một VLAN qua hàng chục, hàng trăm switch mà không biến toàn bộ mạng thành một vùng loop khổng lồ.

Ba câu hỏi cốt lõi mà riêng Phần 1 này trả lời:

  1. Vì sao data center buộc phải chuyển từ mô hình 3 tầng truyền thống sang leaf-spine, và vì sao sự chuyển đổi đó lại "làm mất" khả năng stretch VLAN theo cách cũ (Mục 2)?
  2. EVPN dùng đúng cơ chế gì — route, không phải flood — để một VLAN vẫn "stretch" được qua một hạ tầng đã hoàn toàn layer 3 (Mục 3, 5)?
  3. Vì sao cần tới hai loại VRF khác nhau (MAC VRF và IP VRF) chỉ để làm một việc tưởng như đơn giản: định tuyến giữa hai VLAN (Mục 7, 9)?

Loạt bài này dựa trên tinh thần giảng dạy của Tony Bourke (Packet Pushers): dạy EVPN không dùng bất kỳ dòng cấu hình nào. Lý do không phải để làm màu — mà vì trình tự học sai (cấu hình trước, khái niệm sau) là nguyên nhân phổ biến khiến kỹ sư mạng sợ EVPN. Khi bạn copy một block cấu hình BGP address-family từ tài liệu, dán vào switch, và nó không hoạt động, bạn sẽ không biết sửa ở đâu — vì bạn chưa từng hiểu tại sao cần address-family đó, tại sao cần khai báo VTEP theo cách đó. Tài liệu này đảo ngược trình tự: hiểu khái niệm trước, để khi đọc cấu hình thật ở phần sau, bạn biết chính xác mỗi dòng đang giải quyết vấn đề gì.

Phạm vi cụ thể ở đây là MP-BGP EVPN over VXLAN — tổ hợp công nghệ phổ biến nhất trong data center hiện đại, và ngày càng được dùng cả ở mạng campus. Ở campus, use case điển hình là multi-tenancy: tách nhiều business unit ra khỏi nhau về mặt logic dù dùng chung hạ tầng vật lý. Trong mô hình campus truyền thống, vị trí của một người vừa là địa điểm vừa là danh tính — địa chỉ IP của bạn gắn chặt với tầng nhà, khu vực wifi bạn đang đứng. Với EVPN, danh tính (thông qua NAC — Network Access Control) có thể tách rời hoàn toàn khỏi vị trí vật lý: bạn có thể ở bất kỳ tòa nhà, tầng nào, nhưng vẫn nhận đúng một chính sách bảo mật, vì "segment" của bạn không còn bị trói vào một dây cáp cụ thể mà có thể trải rộng trên nhiều thiết bị.

💡 Hình dung như thế này: học EVPN cũng giống dân mạng lần đầu học Python — nhìn từ ngoài có vẻ đáng sợ, nhưng khi thực sự bắt tay vào thì phần lớn khái niệm đã quen thuộc từ networking truyền thống (VLAN, routing, BGP), chỉ là được lắp ráp lại theo một cách mới.

2. Tại sao cần EVPN?​

Bài toán của data center truyền thống​

Trước khi hiểu EVPN giải quyết gì, cần hiểu rõ vấn đề nó sinh ra để giải quyết. Mạng data center truyền thống (phổ biến từ khoảng 2006–2008) có cấu trúc 3 tầng: core → aggregation → access. Default gateway của các VLAN đặt ở tầng aggregation, chạy giao thức dự phòng cổng gateway đầu tiên (FHRP — First Hop Redundancy Protocol) như HSRP/VRRP: một thiết bị active, một thiết bị standby. Ranh giới layer 3 (nơi bắt đầu routing) nằm ngay tại tầng aggregation; mọi thứ bên dưới nó là thuần layer 2 (switching, không routing).

Lý do phải giữ một vùng layer 2 lớn như vậy: để hỗ trợ vMotion — tính năng di chuyển một máy ảo (VM) đang chạy từ hypervisor vật lý này sang hypervisor khác mà không tắt máy. Có một điểm hay bị hiểu nhầm ở đây: từ VMware vSphere 6.0 (khoảng 2015), VMware đã bỏ yêu cầu bắt buộc bản thân VM phải nằm trong cùng một vùng layer 2 — nhưng vẫn yêu cầu các VMkernel interface (địa chỉ IP quản lý của từng hypervisor, dùng để truyền dữ liệu vMotion) phải nằm cùng subnet. Quan trọng hơn: dù VMkernel có được nới lỏng, layer 2 segment mà VM đang chạy vẫn phải tồn tại trên mọi hypervisor mà VM có thể di chuyển tới — vì khi VM chuyển tới nơi mới, traffic từ Internet/nơi khác gửi đến vẫn phải tìm đúng đường tới nó, nghĩa là default gateway phục vụ subnet đó phải reach được VM ở vị trí mới.

Cách làm truyền thống để đạt được điều này: bật VLAN đó trên toàn bộ switch tầng access, trunk (802.1Q) xuống mọi hypervisor có thể chứa VM đó. Kết quả: layer 2 domain trải rộng khắp hạ tầng — đánh đổi lấy một vùng broadcast/loop khổng lồ.

Vấn đề thứ hai của mô hình 3 tầng: tầng core/aggregation thường chỉ có 2 thiết bị (để chạy FHRP active/standby). Mất một thiết bị là mất 50% capacity và toàn bộ dự phòng — nên buộc phải dùng chassis switch (nhiều fabric module, line card, supervisor, nguồn dự phòng bên trong một khung máy) để đạt độ sẵn sàng cao. Chassis switch thì đắt, và càng lớn càng khó mở rộng thêm.

Leaf-Spine: câu trả lời về mặt topology​

Xu hướng chuyển dịch là sang leaf-spine topology — dùng nhiều switch top-of-rack/end-of-row nhỏ gọn, rẻ hơn nhiều so với chassis, và khi cần thêm băng thông chỉ cần mua thêm leaf/spine thay vì nâng cấp một khung máy khổng lồ.

Traditional 3-Tier vs Leaf-SpineTraditional (Core/Agg/Access)Core / Aggregation (L3)Access Switch (L2 only)Hypervisors (VM, same VLAN)Chỉ 2 thiết bị core → mất 1 = mất 50% capacityLeaf-SpineSpine1Spine2Leaf1Leaf2Leaf3tất cả link đều Layer 3Cần thêm băng thông → chỉ cần thêm leaf/spineVấn đề: leaf-spine thuần Layer 3 thì vMotion (cần Layer 2) hoạt động thế nào?EVPN trả lời câu hỏi này: nó cho phép "stretch" (kéo dài) một layer 2 segmentqua TẤT CẢ các leaf, dù bản thân kết nối leaf–spine vẫn hoàn toàn là Layer 3.Default gateway cũng đặt ngay tại leaf dưới dạng Anycast Gateway —cùng một địa chỉ IP gateway tồn tại giống hệt nhau trên mọi leaf.→ Đây chính là lý do EVPN tồn tại. Mục 3 sẽ nói cách nó được xây dựng.

Nhưng chuyển sang leaf-spine đặt ra một câu hỏi hóc búa: nếu mọi kết nối leaf–spine đều là layer 3 thuần túy (routing, không trunk VLAN), thì vMotion — thứ vốn cần layer 2 — sẽ hoạt động thế nào? Đây chính xác là bài toán mà EVPN sinh ra để giải quyết: stretch (kéo dài) một layer 2 segment qua tất cả các leaf, trong khi bản thân hạ tầng vật lý bên dưới (leaf–spine) vẫn hoàn toàn là layer 3 — có routing protocol xử lý failover, tính khả dụng, ECMP (cân bằng tải đa đường) như bất kỳ mạng layer 3 nào khác.

Một hệ quả tự nhiên khi default gateway giờ đặt ngay tại leaf: Anycast Gateway — cùng một địa chỉ IP gateway (và cùng MAC) tồn tại giống hệt nhau trên mọi leaf trong fabric. VM ở bất kỳ leaf nào cũng thấy "gateway của tôi ở ngay đây", giúp giảm hiện tượng traffic phải đi vòng (trombone/hairpin) chỉ để tới đúng gateway vật lý duy nhất. Có cơ chế phía sau (sẽ nói ở các phần sau) ngăn vấn đề "tôi là Spartacus" — nhiều thiết bị cùng khai báo một IP mà không gây xung đột ARP. Về đại khái, cơ chế này gọi là ARP suppression: thay vì để ARP request bị flood ra khắp fabric như một VLAN truyền thống vẫn làm, leaf nhận request tự trả lời thay cho gateway (vì gateway ở leaf nào cũng giống hệt nhau) — triệt tiêu request ngay tại chỗ, không để nó đi xa hơn. Cách leaf tra đúng thông tin để trả lời sẽ rõ hơn khi học route Type 2 ở phần sau.

Vì sao không dùng công nghệ khác đã có sẵn?​

Trước EVPN đã có vài nỗ lực khác để giải bài toán tương tự — FabricPath (Cisco), Brocade VCS (dựa trên TRILL), shortest path bridging. Một số nơi quy mô lớn vẫn còn dùng, nhưng nhìn chung EVPN đã thắng thế và là cách làm phổ biến nhất hiện nay. Công nghệ gần giống nhất về mặt topology là Cisco ACI — cũng layer 3, cũng dựa trên VXLAN, cũng có một routing protocol bên dưới, nhưng có khác biệt quan trọng: EVPN là chuẩn công nghiệp mở (RFC, đa vendor), còn ACI là sản phẩm độc quyền của Cisco. Vì phần lớn triển khai thực tế chỉ dùng một vendor cho toàn bộ fabric (không ai xây EVPN đa vendor trong cùng một fabric), khác biệt này ít khi là yếu tố quyết định — nhưng lợi ích thực sự của EVPN nằm ở chỗ khái niệm giống nhau trên mọi vendor: học EVPN một lần, áp dụng được cho Cisco, Arista, Juniper, và hiểu ACI cũng dễ hơn hẳn.

3. Xây dựng topology EVPN: Underlay & Overlay​

Để dựng một mạng EVPN, cần ba lớp: topology (đã nói ở Mục 2 — leaf-spine), underlay, và overlay. Đây là hai thuật ngữ sẽ xuất hiện xuyên suốt toàn bộ tài liệu, nên cần định nghĩa rõ ngay từ đầu:

  • Underlay: một mạng layer 3 thuần túy, đơn giản, chỉ có một nhiệm vụ — đảm bảo mọi thiết bị trong fabric ping được lẫn nhau qua địa chỉ loopback. Không có khái niệm VLAN, VRF, hay tenant nào ở đây.
  • Overlay: các "đường hầm" (tunnel) chạy bên trên underlay, mang traffic thật của VM/tenant. Overlay dùng underlay chỉ để hai đầu tunnel tìm thấy nhau — bản thân overlay không quan tâm underlay dùng giao thức gì.
Underlay vs OverlayOverlay (MP-BGP EVPN)Tunnel VXLAN mang traffic thật của VM — chỉ leaf mới có, dùng Loopback1 (VTEP)"Tôi cần đến VTEP 2.2.2.2" — không quan tâm underlay là OSPF hay BGPUnderlay (OSPF / IS-IS / BGP)Chỉ một nhiệm vụ: mọi Loopback0 phải ping được mọi Loopback0 khácKhông biết VLAN, VRF, hay tenant nào tồn tại phía trên nóVí dụ cụ thể — 2 leaf, 1 spine, chạy trên nền underlay ở trên:SpineLeaf1Lo0=10.0.0.1Leaf2Lo0=10.0.0.2VXLAN tunnel: Lo1 10.1.1.1 ↔ Lo1 10.1.1.2 (VTEP)Overlay "mượn" underlay để 2 VTEP tìm thấy nhau — không hơn không kém

Underlay: mọi loopback phải thấy nhau​

Convention (không phải yêu cầu bắt buộc trong RFC, mà là quy ước ngành đã trở thành gần như phổ quát) là dùng hai loopback trên mỗi thiết bị:

  • Loopback0: dùng cho routing protocol underlay — chạy trên mọi thiết bị (cả leaf lẫn spine).
  • Loopback1: dùng làm địa chỉ VTEP (Virtual Tunnel Endpoint) — điểm cuối của tunnel VXLAN. Chỉ leaf mới cần, vì spine không terminate tunnel (tunnel luôn đi từ leaf tới leaf, băng qua spine chỉ như một trạm trung chuyển layer 3 thuần túy).

Mục tiêu duy nhất của underlay: mọi Loopback0 phải reach được mọi Loopback0 khác. Không hơn, không kém. Giao thức nào cũng dùng được miễn đạt mục tiêu này — kể cả RIP (đã có người thử cho vui, nhưng không khuyến khích vì RIP không hỗ trợ ECMP). Lựa chọn phổ biến trong thực tế: OSPF, IS-IS (ít gặp hơn), iBGP hoặc eBGP.

Nếu dùng OSPF/IS-IS, có thể dùng IP unnumbered (tùy vendor hỗ trợ). Nếu dùng BGP (cả iBGP lẫn eBGP), bắt buộc phải đánh số point-to-point — thường dùng /31 cho mỗi liên kết leaf–spine.

💡 Lời khuyên khi mới học: dùng OSPF một area 0 duy nhất, không cầu kỳ làm underlay. Lý do: giữ ranh giới thật rõ ràng — nhìn vào OSPF là biết đang xem underlay, nhìn vào BGP là biết đang xem overlay/EVPN. Có tin đồn ngưỡng ~100 leaf là giới hạn của OSPF underlay, nhưng chưa có test cụ thể nào chứng minh con số này; thực tế đã có người scale vượt xa mốc đó.

Underlay khá tĩnh — routing table gần như không đổi theo thời gian. Mọi sự sôi động, mọi "phép màu" của EVPN, đều nằm ở overlay.

Overlay: MP-BGP mang theo địa chỉ MAC​

Overlay luôn luôn là MP-BGP (Multiprotocol BGP) với address family tên là evpn. "MP" (multiprotocol) là vì BGP nguyên gốc chỉ hỗ trợ IPv4 — cần phần mở rộng multiprotocol để mang thêm các loại thông tin khác, ở đây là MAC address và VNI.

Đây là điểm khác biệt cốt lõi so với BGP truyền thống mà bạn đã quen: BGP thông thường chỉ route IP prefix (network). BGP EVPN route thêm cả MAC address và host IP (/32 hoặc /128) — nói cách khác, EVPN "route" địa chỉ MAC giống hệt cách BGP thường route một network.

Nhưng vì sao lại chọn đúng BGP cho việc này, thay vì một link-state protocol quen thuộc hơn (OSPF, IS-IS) hay một cơ chế tự chế nào khác? Ba lý do gắn chặt với chính bản chất của BGP:

  1. BGP vốn đã là một policy language (sẽ thấy rõ ở Mục 4 với RD/RT) — cơ chế import/export theo Route Target gần như khớp hoàn hảo với nhu cầu multi-tenant: mỗi tenant chỉ nhận đúng route của mình, không cần dựng thêm một lớp policy riêng biệt nào khác.
  2. BGP đã được chứng minh scale tới hàng trăm nghìn, hàng triệu route trên Internet toàn cầu — một fabric data center, dù lớn tới đâu, vẫn nhỏ hơn nhiều so với global routing table, nên BGP dư sức xử lý.
  3. BGP là soft-state, không cần hội tụ tức thời — đây là điểm dễ bị bỏ qua nhất. Khi một link vật lý đứt, đó là việc của underlay (OSPF/IS-IS/BGP underlay) xử lý failover trong mili-giây; overlay chỉ cần phản ứng khi có sự kiện thật sự liên quan tới MAC/IP (host di chuyển, host mới xuất hiện) — những sự kiện này xảy ra chậm hơn nhiều so với link flap. Overlay không cần một giao thức hội tụ nhanh như link-state; dùng BGP cho việc "chậm mà chắc" này là vừa đủ, không thừa không thiếu.
  • Nếu dùng iBGP: các spine đóng vai trò Route Reflector, giúp mỗi leaf chỉ cần peer với spine thay vì phải full-mesh với tất cả leaf khác.
  • Nếu dùng eBGP: spine dùng chung một AS, mỗi cặp leaf (thường triển khai MLAG/vPC) có AS riêng — giúp nhận diện leaf nguồn của một route qua as-path.

Sự khác biệt này không phải "chọn cho gọn" — nó bắt nguồn trực tiếp từ cách mỗi biến thể BGP chống loop, và đáng để hiểu kỹ vì đây là chỗ rất nhiều người học EVPN chỉ nhớ luật mà không hiểu vì sao.

Với iBGP: mọi speaker chia sẻ chung một AS number nên iBGP không dùng AS_PATH để chống loop — thay vào đó nó dựa vào luật iBGP split-horizon: một route học được từ một iBGP peer thì không được re-advertise cho một iBGP peer khác. Luật này ngăn loop rất tốt, nhưng có tác dụng phụ: nếu để leaf tự peer trực tiếp với nhau, mỗi leaf sẽ phải full-mesh với mọi leaf còn lại (vì không leaf nào được re-advertise route hộ leaf khác). Route Reflector tồn tại chính để phá luật đó một cách có kiểm soát: spine (đóng vai trò RR) được phép nhận route từ một leaf rồi phản xạ (reflect) sang mọi leaf khác — giải quyết đúng vấn đề mà split-horizon gây ra, đổi lại loop được ngăn bằng cơ chế khác (route-reflector cluster-list/originator-id) chứ không phải AS_PATH.

Với eBGP: ngược lại, AS_PATH chính là cơ chế chống loop — một router eBGP mặc định sẽ từ chối bất kỳ route nào đã chứa ASN của chính nó trong AS_PATH. Đây là lý do vì sao mỗi leaf (hoặc mỗi cặp leaf MLAG) bắt buộc phải có AS riêng biệt: nếu hai leaf dùng chung một AS, một route mà leaf này gửi lên có thể đi vòng qua fabric và quay trở lại đúng leaf kia (khác thiết bị vật lý nhưng cùng AS) — router sẽ tưởng đây là loop và âm thầm loại bỏ route, dù topology hoàn toàn hợp lệ.

Vậy vì sao ngược lại các spine lại cố tình dùng chung một AS, thay vì mỗi spine một AS riêng cho "an toàn"? Hai lý do:

  1. Trong một fabric Clos 3-tầng chuẩn, route không bao giờ đi từ spine quay ngược lại chính spine đó — nên spine dùng chung AS không tạo ra loop giả nào cả.
  2. Quan trọng hơn, đây chính là điều giúp ECMP hoạt động ngay lập tức mà không cần cấu hình thêm: nếu leaf B nhận cùng một prefix qua cả Spine1 lẫn Spine2, và hai spine dùng chung AS, thì AS_PATH của hai route đó giống hệt nhau về nội dung, không chỉ giống độ dài — hầu hết implementation BGP sẽ tự động ECMP giữa hai path như vậy. Nếu mỗi spine có AS riêng, AS_PATH tuy vẫn cùng độ dài nhưng khác nội dung (khác ASN ở giữa), và nhiều vendor mặc định sẽ không ECMP giữa các path có AS_PATH khác nội dung — phải bật thêm một flag riêng (ví dụ "bestpath as-path multipath-relax" trên một số nền tảng) mới ECMP được. Dùng chung AS ở spine giúp tránh hẳn việc phải nhớ bật flag đó.

Tóm gọn một câu: iBGP chống loop bằng luật split-horizon nên cần Route Reflector để phá luật đó có kiểm soát; eBGP chống loop bằng AS_PATH nên cần AS riêng ở leaf để không tự loại bỏ route của chính mình, và cần AS chung ở spine để ECMP không cần cấu hình thêm.

Bảng routing sẽ lớn dần khi fabric mở rộng, nhưng phần cứng hiện đại xử lý control-plane khá tốt. Giới hạn thực sự nằm ở forwarding table (TCAM/CAM) — một leaf không nhất thiết phải cài route vào phần cứng trừ khi có segment liên quan cục bộ, giúp tiết kiệm tài nguyên đáng kể.

Ở quy mô lớn, cấu hình thủ công gần như chắc chắn sẽ sai sót (một IP point-to-point gõ nhầm là đủ khó tìm khi mọi leaf trông giống hệt nhau) — nên triển khai EVPN gần như bắt buộc phải dùng automation (Ansible, Arista CloudVision, Cisco DCNM...), không cấu hình tay. Cùng với đó, cần đầu tư đào tạo đội ngũ vận hành — thiếu hiểu biết của đội vận hành là nguyên nhân phổ biến khiến một triển khai EVPN thất bại trong thực tế.

Cuối cùng, một đặc điểm quan trọng của tunnel VXLAN: nó stateless. Không cần đàm phán thiết lập tunnel như VPN concentrator truyền thống, không cần giữ kết nối — encap/decap diễn ra tự động theo traffic, và mỗi leaf chỉ cần một cấu hình tunnel duy nhất, không phải cấu hình riêng cho từng segment.

💡 Hình dung như thế này: khác hẳn hình ảnh "VPN concentrator" cũ (phải bấm mã token, khó bảo trì). Tunnel VXLAN giống một cánh cửa tự động — chỉ hiện ra khi có người bước tới, biến mất ngay khi không ai dùng, không cần ai đứng canh giữ nó mở.

4. VRF cơ bản: Route Distinguisher & Route Target​

Phần này là nơi rất nhiều người học EVPN bị "khựng" lại — không phải vì nó khó, mà vì nó thường bị lướt qua quá nhanh trong tài liệu, trong khi đây chính là chỗ 90% lỗi cấu hình EVPN thực tế xảy ra.

VRF (Virtual Route Forwarding instance) là một khái niệm bạn có thể đã quen: một bảng định tuyến (routing table) độc lập, tách biệt hoàn toàn khỏi bảng định tuyến mặc định. Interface được gán vào một VRF cụ thể; nó chỉ trao đổi route với các interface khác cùng VRF. Hệ quả hữu ích nhất: hai VRF khác nhau có thể overlap địa chỉ IP mà không xung đột — VRF Red có thể có 10.1.1.1, VRF Blue cũng có 10.1.1.1, và chúng sống trong hai không gian địa chỉ hoàn toàn tách biệt.

Vấn đề: một liên kết, nhiều VRF cần trao đổi route​

Vấn đề nảy sinh khi bạn cần trao đổi route của nhiều VRF khác nhau qua cùng một kết nối vật lý/BGP session — điều mà routing protocol thông thường không có cách nào phân biệt được, vì bản thân BGP không có khái niệm "VRF" khi đóng gói một route để gửi đi. Đây là lý do cần hai công cụ: Route Distinguisher (RD) và Route Target (RT) — hai khái niệm trông giống hệt nhau về mặt cú pháp nhưng có vai trò hoàn toàn khác nhau, và chính điều đó gây nhầm lẫn.

Route Distinguisher vs Route TargetVRF Red — 10.1.1.1Export RT: 10:10RD: Loopback:1 (unique)VRF Blue — 10.1.1.1Export RT: 20:20RD: Loopback:2 (unique)BGP table chung (bgp.evpn.0)RD giúp 2 route "10.1.1.1" không đè lên nhauImport RT 10:10 tại Leaf khác→ route được đẩy vào VRF RedRT KHÔNG khớp 20:20 → route Blue bị bỏ quaImport RT 20:20 tại Leaf khác→ route được đẩy vào VRF BlueRT KHÔNG khớp 10:10 → route Red bị bỏ qua

Route Distinguisher (RD) — chỉ để làm route "độc nhất"​

RD được gắn thêm vào mỗi route trước khi nó đi vào bảng BGP chung (thường ghép từ địa chỉ loopback + một số hậu tố, ví dụ 10.0.0.1:1), với một mục đích duy nhất: đảm bảo route không bị trùng/đè lẫn nhau khi nhiều VRF cùng đẩy route vào một bảng BGP chung để trao đổi qua các peering session. RD không quyết định gì khác — nó không ảnh hưởng route có được chấp nhận hay không, không quyết định route sẽ rơi vào VRF nào ở phía nhận. Thiết bị nhận thấy RD chỉ đơn giản "ghi nhận" nó tồn tại.

RD hầu như không cần khớp giữa các thiết bị — trên thực tế gần như luôn khác nhau, và nhờ vậy còn có thể dùng để nhận diện route đến từ leaf nào (hữu ích khi debug, nhất là lúc dùng iBGP và không có AS number riêng để phân biệt).

Về mặt kỹ thuật, RD có ba dạng encoding khác nhau (RFC 4364 §4.2), phân biệt bằng 2 byte Type ở đầu: Type 0 (ASN 2-byte : số tuỳ ý 4-byte, ví dụ 65001:100), Type 1 (địa chỉ IPv4 4-byte : số tuỳ ý 2-byte, ví dụ 10.0.0.1:1 — dạng phổ biến nhất trong EVPN vì thường ghép thẳng từ Loopback0), và Type 2 (ASN 4-byte : số tuỳ ý 2-byte, dùng khi ASN đã ở dạng 4-byte). Định dạng cụ thể không quan trọng bằng việc nhớ nguyên tắc cốt lõi: RD không cần khớp giữa hai đầu — khác hẳn RT.

Route Target (RT) — quyết định route đi vào đâu​

RT mới là phần quan trọng thực sự. Nó hoạt động theo cặp export/import:

  • Export: khi một VRF/forwarding-space announce một route ra ngoài, nó gắn kèm một RT — giống như dán một cái nhãn lên route đó.
  • Import: thiết bị nhận route sẽ soi RT trên route, so khớp với danh sách RT mà nó chấp nhận nhập vào, rồi mới quyết định đẩy route đó vào đúng VRF cục bộ nào.

Khác với RD, RT bắt buộc phải khớp chính xác giữa bên export và bên import thì route mới đi đúng chỗ.

RD gần như không bao giờ gây lỗi (kể cả khi thiếu, hệ thống vẫn chạy dù có thể gặp hành vi lạ). Ngược lại, RT chính là nơi phần lớn lỗi cấu hình EVPN xảy ra — và cũng là trọng tâm chính khi troubleshoot. Ghi nhớ nguyên tắc này ngay từ bây giờ, vì bạn sẽ gặp lại RT ở hầu như mọi phần còn lại của loạt bài, đặc biệt là ở các phần sau khi nói về multi-site.

5. MAC VRF / Layer 2 VNI​

EVPN dùng ba loại "không gian chuyển tiếp" (forwarding space) riêng biệt trên mỗi thiết bị: một VRF tenant tổng (nói ở Mục 7), một MAC VRF cho mỗi VLAN cần kéo dài (mục này), và một IP VRF để routing giữa các VLAN đó (Mục 7). Mục này tập trung vào MAC VRF.

MAC VRF là một forwarding space chỉ chứa địa chỉ MAC — về bản chất, nó chính là một bảng bridging (bridging table). Trên thiết bị vật lý, MAC VRF được hiện thực bằng một VLAN cục bộ: mỗi VXLAN segment (gọi là VNI — VXLAN Network Identifier) có quan hệ 1-1 với một VLAN local trên switch. MAC VRF còn được gọi là Layer 2 VNI; xét ở data-plane, nó hoạt động y hệt một VLAN được kéo dài qua nhiều switch (stretched VLAN).

Học MAC theo kiểu cũ vs kiểu EVPN​

Cách học MAC address truyền thống là flood & learn: switch chưa biết MAC nằm ở đâu thì flood ra mọi port, ai trả lời thì switch ghi nhớ. Với EVPN, cách học này vẫn tồn tại nhưng chỉ ở phạm vi local (leaf vẫn flood ra các port cùng VLAN theo kiểu truyền thống khi cần). Vấn đề là: các leaf trong một fabric EVPN không nối trực tiếp layer 2 với nhau — chúng chỉ nối qua underlay layer 3. Flood truyền thống không thể băng qua layer 3 được. Đây chính là chỗ EVPN can thiệp: thay vì flood, nó dùng route để phổ biến thông tin MAC.

Type 2 Route: Learning a Remote MACLeaf1 (VTEP 1.1.1.1)VLAN 101 learns:MAC 00:...:01(local flood/learn)generateEVPN Type 2 RouteMAC: 00:...:01RT: 101:101 (= VNI 1001)Next-hop (VTEP): 1.1.1.1→ gửi qua MP-BGPLeaf2 (VTEP 2.2.2.2)RT khớp VLAN 101→ cài vào MAC table00:...:01 via vxlan1Sau đó — Data Plane khi Leaf2 cần gửi cho MAC đóHost trên Leaf2Leaf2 tra MAC table→ next-hop VTEP 1.1.1.1Encap VXLANVNI=1001, dst=1.1.1.1Gói tin đi qua underlay tới Leaf1Leaf1: decap → xem VNI 1001→ đẩy vào VLAN 101 → forward ra đúng port

Khi một leaf học được một MAC address cục bộ, nó sinh ra một EVPN Type 2 route và gửi qua MP-BGP. Route này chứa:

  • Route Distinguisher và Route Target (RT tương ứng với VLAN/VNI, ví dụ 101:101 khớp VLAN 101, hoặc dùng thẳng VNI như 1001:2001 — con số cụ thể không quan trọng, miễn hai đầu khớp nhau).
  • Địa chỉ MAC vừa học được.
  • Địa chỉ VTEP nơi MAC đó đang cư trú.

Leaf nhận route sẽ soi RT, khớp với cấu hình cục bộ, và biết cần cài MAC đó vào bảng forwarding của đúng VLAN, với next-hop là cổng logic VXLAN trỏ về VTEP nguồn. Nếu một leaf nhận route nhưng không có VLAN/RT tương ứng cấu hình cục bộ, route đó vẫn tồn tại trong RIB (BGP table) nhưng không được cài vào phần cứng (TCAM) — tiết kiệm tài nguyên forwarding cho những segment mà leaf đó không cần quan tâm.

💡 Hình dung như thế này: Route Target đóng vai trò tương tự một thẻ tag 802.1Q khi bạn trunk hai switch vật lý — báo cho switch nhận biết frame này thuộc VLAN nào. Khác biệt duy nhất: 802.1Q tag là một phần của data plane (gắn trực tiếp vào từng frame vật lý), còn RT hoạt động ở control plane (gắn vào route BGP, không đụng tới frame thật).

Một câu hỏi tự nhiên hay bị bỏ sót: nếu MAC chỉ được học sau khi leaf nhìn thấy traffic từ host đó, vậy điều gì xảy ra với gói tin đầu tiên gửi tới một host còn "im lặng" (chưa từng gửi gì, nên chưa leaf nào học được MAC của nó)? Đây chính là lúc cần tới traffic BUM (Broadcast, Unknown-unicast, Multicast). EVPN có hẳn một loại route riêng — Type 3, Inclusive Multicast Ethernet Tag route — để các leaf biết cần replicate loại traffic này tới đúng những leaf nào đang có cùng VLAN, thay vì mù quáng flood ra toàn mạng như flood truyền thống. Route Type 3 sẽ được nói kỹ ở phần sau.

MAC VRF chỉ là một nửa câu chuyện — vậy nửa còn lại là gì?​

Đến đây, MAC VRF (Layer 2 VNI) đã đủ để giải quyết đúng một việc: hai host cùng VLAN, tức cùng subnet, gửi được cho nhau qua route thay vì flood. Nhưng MAC VRF về bản chất vẫn chỉ là một bảng bridging — nó chỉ biết MAC, không biết gì về IP, và không định tuyến được. Vậy khi Host A ở VLAN 101 muốn nói chuyện với Host B ở VLAN 102 (khác subnet, bắt buộc cần routing, không chỉ bridging), MAC VRF một mình là không đủ. Đây chính xác là lý do EVPN cần thêm một forwarding space thứ hai — IP VRF (Layer 3 VNI): nơi duy nhất trong toàn bộ tenant biết cách đi giữa các VLAN, thay vì chỉ đi bên trong một VLAN. IP VRF sẽ được trình bày đầy đủ (kèm packet walkthrough) ở Mục 7 — nhưng để không rời Mục 5 với cảm giác "vẫn chưa rõ hai cái này khác nhau ở đâu", hãy nhìn thẳng vào cấu trúc bên dưới trước.

MAC VRF vs IP VRF — Same VLAN vs Cross-VLAN TrafficTenant VRF ("kirk")IP VRF — L3 VNI 90000Routing giữa các VLAN trong cùng tenant1 per tenant · có mặt trên MỌI leaf (symmetric)khác VLAN → qua IP VRF trướcMAC VRF — VLAN 101 (L2 VNI 10101)Host A1Host A2cùng VLAN → chỉ đi qua MAC VRFchỉ leaf đang host VLAN 101 mới cần MAC VRF nàyMAC VRF — VLAN 102 (L2 VNI 10102)Host B1chỉ leaf đang host VLAN 102 mới cần MAC VRF nàyMAC VRF: nhiều cái, chỉ nơi có VLAN đó · IP VRF: đúng 1 cái, bắt buộc có ở mọi leaf trong tenant

Đi theo đúng hai luồng trong sơ đồ trên để thấy rõ khác biệt:

  • Host A1 → Host A2 (cùng VLAN 101, cùng subnet): đây thuần túy là bridging. Leaf tra MAC table trong đúng MAC VRF của VLAN 101, thấy Host A2, forward thẳng — gói tin không bao giờ chạm tới IP VRF. Với luồng này, IP VRF có tồn tại hay không cũng không quan trọng.
  • Host A1 → Host B1 (khác VLAN, khác subnet): Host A1 gửi gói tin tới default gateway của VLAN 101 trước (packet đi vào MAC VRF 101, nhưng đích đến là một subnet khác nên MAC VRF không đủ thông tin để forward tiếp). Gói tin được đẩy lên IP VRF — nơi duy nhất biết "muốn tới subnet của VLAN 102 thì đi đâu" — rồi từ IP VRF mới được đẩy xuống đúng MAC VRF của VLAN 102 để bridge nốt chặng cuối tới Host B1.

Điểm mấu chốt: MAC VRF không bao giờ nói chuyện trực tiếp với một MAC VRF khác. Mọi traffic đi giữa hai VLAN, dù trên cùng một leaf hay khác leaf, đều bắt buộc phải "ghé qua" IP VRF — đây chính là lý do tại sao mô hình này được gọi là Integrated Routing and Bridging: bridging (MAC VRF) và routing (IP VRF) là hai cơ chế tách biệt, nhưng được tích hợp trong cùng một thiết bị, cùng một tenant.

Bảng dưới tóm lại khác biệt theo từng tiêu chí:

Tiêu chíMAC VRF (Layer 2 VNI)IP VRF (Layer 3 VNI)
Vai tròBảng bridging — forward theo MAC, trong cùng một VLANBảng routing — forward giữa các VLAN khác nhau, trong cùng một tenant
Số lượng mỗi tenantNhiều — một MAC VRF cho mỗi VLAN cần stretchĐúng một — dùng chung cho mọi VLAN thuộc tenant đó
Tồn tại trên leaf nàoChỉ leaf đang thực sự host VLAN đó mới cần cóMọi leaf trong tenant, kể cả leaf không host VLAN nào của tenant (tính chất "symmetric" — xem Mục 7)
Route populateEVPN Type 2 (phần MAC) + Type 3 (BUM)EVPN Type 2 (phần host route /32, xem Mục 9) — về sau còn có Type 5 cho route theo prefix, nói ở phần sau của loạt bài

💡 Hình dung như thế này: MAC VRF giống sổ địa chỉ nội bộ của từng tòa nhà trong một khu đô thị — chỉ nhân viên phụ trách tòa đó mới cần giữ một bản, và họ chỉ biết giao thư trong nội bộ tòa nhà mình. IP VRF giống bản đồ quy hoạch toàn khu đặt ở một trạm trung chuyển trung tâm — bất kỳ thư nào đi giữa hai tòa nhà khác nhau đều phải ghé qua trạm này trước, dù người gửi và người nhận không hề hay biết có bước trung chuyển đó.

6. Stretched VLAN & Spanning Tree​

Nghe tới việc "kéo dài một VLAN qua hàng chục switch", phản xạ tự nhiên của bất kỳ ai từng học networking là nghĩ ngay đến rủi ro loop. Câu trả lời thẳng thắn: về bản chất, việc này không hẳn an toàn hơn theo nghĩa tuyệt đối — nhưng cách EVPN thực hiện nó tránh được vấn đề loop nhờ một nguyên tắc rất quen thuộc.

Nhắc lại nguyên tắc nền tảng của Ethernet: không bao giờ để tồn tại nhiều hơn một đường đi giữa hai địa chỉ MAC — nếu có, sẽ sinh loop, và loop gây đủ loại vấn đề (bão broadcast, MAC table flap...). Spanning Tree ra đời chính để ngăn nhiều hơn một path tồn tại. LAG (link aggregation) cho phép nhiều path vật lý nhưng gộp lại thành một path logic duy nhất — về bản chất là "đánh lừa Ethernet" (Ethernet chỉ thấy một link), chứ không phải đánh lừa Spanning Tree.

EVPN áp dụng đúng nguyên lý đó: tạo ra nhiều path vật lý/logic cho traffic đi qua fabric, nhưng đảm bảo không bao giờ tồn tại nhiều hơn một logical path — giống hệt cách LAG hoạt động, chỉ khác ở quy mô.

Một cách nhìn khác, chính xác hơn về mặt kỹ thuật: giữa hai leaf bất kỳ trong fabric, thực chất chỉ tồn tại đúng một hop layer 2 logic duy nhất — vì bên dưới, leaf không hề bridge trực tiếp với leaf khác, chúng chỉ route (layer 3) với nhau qua underlay. Loop layer 2 theo định nghĩa cần có nhiều hơn một đường layer 2 giữa hai điểm — mà ở đây vốn dĩ không hề có "đường layer 2" nào giữa hai leaf để mà loop, chỉ có nhiều đường layer 3 (ECMP) cùng dẫn tới đúng một VTEP đích. Đây là lý do sâu xa hơn khiến EVPN loop-free ngay từ trong thiết kế, không chỉ đơn thuần "giống LAG" — dù phép ví von với LAG vẫn giúp dễ hình dung ở mức khái niệm.

Spanning Tree vẫn chạy trong một mạng EVPN — nhưng chỉ đóng vai trò dự phòng, đề phòng ai đó lỡ cắm nhầm một switch vào switch, tạo loop cục bộ. Trong một mạng EVPN thiết kế đúng, về lý thuyết Spanning Tree không bao giờ cần hành động (không block gì cả) — nhưng vẫn đứng đó canh gác.

Một điểm mấu chốt: BPDU (gói tin của Spanning Tree) không bao giờ được đóng gói và gửi qua tunnel VXLAN. Đây là một dạng split-horizon: switch vẫn gửi BPDU ra các port local trên VLAN đó theo kiểu truyền thống, nhưng không bao giờ gửi BPDU ra interface VXLAN. Nhờ vậy, Spanning Tree hoàn toàn không "nhìn thấy" fabric EVPN — nó chỉ thấy các port truy cập cục bộ.

BPDU Never Crosses the VXLAN TunnelLeaf1Host A (access)Host B (access)BPDU local — bình thườngPortFast + BPDU Guard trên port hostVXLAN interface (VTEP)chỉ mang MAC/IP traffic thật✕BPDU KHÔNG BAO GIỜ đi qua đâyLeaf2Host C (access)Host D (access)BPDU local — bình thườngPortFast + BPDU Guard trên port hostVXLAN interface (VTEP)chỉ mang MAC/IP traffic thật✕BPDU KHÔNG BAO GIỜ đi qua đâyMAC/IP traffic thật vẫn qua tunnel VXLANSplit-horizon: Spanning Tree chỉ thấy port truy cập cục bộ, hoàn toàn không "thấy" fabric EVPN ở giữa

Thực hành phổ biến: các port hướng host được cấu hình kiểu PortFast (một "lời hứa" rằng sẽ không có switch nào khác được cắm vào port đó) kèm BPDU Guard — nếu một port PortFast bất ngờ nhận được BPDU (dấu hiệu ai đó lỡ cắm một switch vào), port đó lập tức bị error-disable, đảm bảo topology vẫn loop-free. Tất nhiên, nếu vô tình nối hai port đều được cấu hình PortFast lại với nhau (cả hai đều "tưởng" mình đang nói chuyện với host), loop vẫn có thể xảy ra — quy tắc này chỉ ngăn được lỗi thường gặp, không phải mọi lỗi cấu hình.

7. IP VRF / Layer 3 VNI với Symmetric IRB​

Đây là phần khiến nhiều người học EVPN "rối" nhất — nhưng một khi ghép được với các khái niệm đã học ở các mục trước, nó sẽ trở nên rất tự nhiên. Hãy đọc chậm phần này.

Best practice (không bắt buộc theo spec, nhưng gần như ai cũng làm): luôn tạo một VRF riêng cho EVPN — gọi nó là gì cũng được, ví dụ "kirk" — thay vì dùng VRF mặc định (default VRF nên để dành riêng cho underlay). Nguyên tắc này giống hệt quy ước "không dùng VLAN 1 cho traffic thật" mà nhiều kỹ sư mạng đã quen: không phải bắt buộc về mặt kỹ thuật, nhưng tránh được rất nhiều rắc rối vận hành về sau.

VRF "kirk" đại diện cho một tenant. Ngay cả khi chỉ có một tenant duy nhất (không multi-tenant), vẫn nên tạo VRF này — mọi interface, default gateway, và bảng định tuyến của EVPN sẽ nằm trong đó. Có thể tạo nhiều VRF tenant khác nhau nếu cần tách biệt traffic theo compliance hay tổ chức.

Bên trong một tenant VRF có hai loại forwarding space khác nhau, và phân biệt được hai loại này chính là chìa khóa để hiểu toàn bộ phần này:

  • Có thể có nhiều MAC VRF (Layer 2 VNI) — một MAC VRF cho mỗi VLAN cần kéo dài (đã học ở Mục 5).
  • Chỉ có một IP VRF duy nhất (Layer 3 VNI) cho mỗi tenant VRF — dùng để routing giữa các MAC VRF/VLAN bên trong cùng tenant đó.

Symmetric IRB là gì?​

IRB (Integrated Routing and Bridging) là tên gọi chung cho việc tích hợp cả routing (layer 3) lẫn bridging (layer 2) vào cùng một cơ chế, thay vì tách thành hai hệ thống riêng biệt. Layer 3 VNI/IP VRF chính là phần "routing" trong IRB.

Trên switch vật lý, phần "routing" đó được hiện thực bằng một SVI (Switch Virtual Interface) — một interface ảo layer 3 gắn với đúng một VLAN cụ thể. Gói tin đi vào VLAN đó ở layer 2; khi cần đi tiếp sang layer 3 (routing sang VLAN khác), nó phải đi qua đúng SVI của VLAN mình. Chính SVI này đóng vai trò default gateway mà mọi host trong VLAN đó trỏ tới — và như sẽ thấy ngay dưới đây, trong EVPN nó tồn tại dưới dạng Anycast Gateway: cùng một SVI, cùng một địa chỉ IP/MAC, có mặt giống hệt nhau trên mọi leaf.

Mô hình được trình bày ở đây là Symmetric IRB — mô hình phổ biến nhất trong thực tế (có một mô hình khác gọi là Asymmetric IRB, không cần IP VRF riêng, nhưng ít được dùng — sẽ so sánh kỹ ở phần sau). "Symmetric" nghĩa là: mọi leaf trong topology đều phải có Layer 3 VNI này — đối xứng trên toàn bộ thiết bị, bất kể leaf đó có đang host VLAN nào hay không.

Một điểm dễ gây nhầm lẫn: trên switch vật lý, mọi VNI — kể cả Layer 3 VNI — đều phải map vào một VLAN cục bộ, dù VLAN đó có thể không chứa host nào cả. Lý do nằm ở chính bản chất VXLAN: nó vốn dĩ là một cơ chế encapsulation ở Layer 2, nên muốn "vay mượn" nó để làm routing (Layer 3), thiết bị vẫn cần một VLAN "giả" làm chỗ gắn SVI/IRB đại diện cho VRF — đây là lý do hầu hết switch, dù Cisco hay Juniper, đều bắt cấu hình thêm một VLAN riêng chỉ để phục vụ Layer 3 VNI, dù VLAN đó không liên quan gì đến VLAN "thật" nào của tenant.

Nhưng VLAN cục bộ này — kể cả VLAN giả phục vụ Layer 3 VNI — không cần đồng nhất giữa các leaf (VD: Layer 3 VNI 90000 của tenant có thể map vào VLAN 999 trên leaf 1 nhưng lại là VLAN 888 trên leaf 2 — vẫn cùng một Layer 3 VNI, chỉ khác số VLAN dùng để hiện thực nó cục bộ trên từng switch). Ngược lại, VNI (VXLAN segment ID) bắt buộc phải globally significant trên toàn fabric — con số VNI phải giống nhau tuyệt đối ở mọi nơi, chính vì VNI mới là thứ EVPN control-plane thực sự dùng để nhận diện route, còn VLAN chỉ là chi tiết hiện thực nội bộ của từng thiết bị.

Lý do cần toàn bộ cơ chế "phức tạp" này: chính vì đã stretch layer 2 (để phục vụ vMotion, như đã nói ở Mục 2), nên khi cần route giữa hai layer 2 segment khác nhau, thay vì dựng hẳn một hệ thống routing tách biệt hoàn toàn bên ngoài EVPN (phức tạp hơn nhiều), EVPN tích hợp luôn phần routing vào cùng cơ chế.

Đi theo một gói tin thật, từng bước​

Đây là phần quan trọng nhất của cả Phần 1 — nếu hiểu được luồng dưới đây, bạn đã hiểu được phần lõi khó nhất của EVPN.

Giả sử Host 1 (10.1.1.11, VLAN 101) muốn gửi packet tới Host 2 (10.1.2.50, VLAN 102) — khác subnet, nên chắc chắn cần routing:

Symmetric IRB — Host1 → Host2 (khác subnet)Host110.1.1.11 / VLAN101Host210.1.2.50 / VLAN102Leaf1 (VTEP 1.1.1.1)① SVI Anycast GW 10.1.1.1② Layer 2 VNI không đủ IP info→ đẩy lên Layer 3 VNI (IP VRF)③ Tra host route trong L3 VNI10.1.2.50/32 → VTEP 3.3.3.3④ Encap VXLAN (L3 VNI)src=1.1.1.1, dst=3.3.3.3Leaf3 (VTEP 3.3.3.3)⑤ Decap, xem VNI đíchVNI khớp VLAN 102 local⑥ Tra MAC table VLAN 102tìm MAC của 10.1.2.50⑦ Forward ra port → Host2Gói tin đi qua underlay (VXLAN, VNI = Layer 3 VNI)
  1. Host 1 gửi packet tới default gateway — một SVI anycast (ví dụ 10.1.1.1 cho VLAN 101) tồn tại giống hệt nhau trên mọi leaf.
  2. Leaf1 nhận packet tại SVI: vì Layer 2 VNI (MAC VRF) chỉ chứa thông tin MAC, không đủ để routing theo IP, packet được đẩy lên Layer 3 VNI (IP VRF).
  3. Trong Layer 3 VNI đã có sẵn các host route dạng /32 — ví dụ 10.1.2.50/32 nằm ở VTEP 3.3.3.3.
  4. Nhờ route này, Leaf1 biết chính xác cần gửi gói tin tới VTEP nào — không cần routing hop-by-hop qua nhiều thiết bị trung gian như một mạng layer 3 truyền thống, nên hiệu quả hơn nhiều.
  5. Gói tin được đóng gói VXLAN (source là VTEP của Leaf1, destination là VTEP của Leaf3) và gửi qua underlay.
  6. Leaf3 nhận, giải gói (decapsulate), dựa vào VNI đích trong header để biết ánh xạ vào VLAN cục bộ nào (VLAN 102).
  7. Sau khi vào đúng VLAN, Leaf3 tra MAC address table cục bộ để forward gói tin ra đúng port vật lý tới Host 2.

Một chi tiết hay bị bỏ qua ở bước ④: khi encapsulate, Leaf1 không chỉ gắn VNI = Layer 3 VNI mà còn viết lại địa chỉ MAC bên trong frame — source MAC giờ là router-MAC của chính Leaf1 (đại diện cho SVI vừa route gói tin), còn destination MAC là router-MAC của Leaf3, thứ mà Leaf1 đã học được từ trước qua EVPN Router's MAC extended community gắn kèm route Type 2 của Leaf3 (xem Mục 9). Nhờ vậy, khi Leaf3 decap ở bước ⑤, nó nhận ra ngay đây là traffic được route tới chính mình (dst MAC khớp router-MAC cục bộ) chứ không phải traffic bridge thông thường — nên biết cần tiếp tục tra IP đích và bridge sang đúng VLAN 102, thay vì chỉ đơn thuần forward theo MAC gốc của Host 1 (MAC đó vốn dĩ Leaf3 còn chưa từng biết tới).

Lưu ý quan trọng: việc forwarding ở data plane luôn dựa vào ánh xạ VNI → VLAN cục bộ trên từng switch — route target chỉ có vai trò populate đúng route vào đúng forwarding-space ở control plane, còn việc chuyển gói tin thực tế dựa vào VNI đích nằm ngay trong header VXLAN của gói tin.

Layer 3 VNI forwarding table phải đồng nhất thông tin trên mọi thiết bị trong fabric — không giống Layer 2 VNI (nơi không phải leaf nào cũng cần có mọi VLAN), mọi leaf đều bắt buộc phải có Layer 3 VNI của tenant đó, kể cả khi leaf đó không host bất kỳ VLAN nào của tenant.

💡 Hình dung như thế này: toàn bộ cơ chế này giống một cỗ máy Rube Goldberg — rất nhiều bộ phận nhỏ phải vận hành đồng bộ (SVI, Layer 2 VNI, Layer 3 VNI, VXLAN encap/decap) chỉ để cuối cùng làm một việc rất đơn giản: đưa một gói tin từ điểm A đến điểm B.

8. Yêu cầu phần cứng cho EVPN​

VTEP là một tính năng phần cứng — cần switch hỗ trợ mới triển khai được ở quy mô lớn, vì việc encapsulate/decapsulate VXLAN diễn ra ở tốc độ đường truyền (line-rate) trên ASIC, không thể xử lý bằng phần mềm nếu muốn hiệu năng thực tế.

Switch hiện đại (trong khoảng 5 năm gần đây, tính từ thời điểm loạt bài gốc được ghi lại) hầu hết đều route được VXLAN. Thế hệ switch VXLAN đời đầu chỉ có thể bridge — nghĩa là chỉ encapsulate HOẶC decapsulate một packet, không làm được cả hai cùng lúc, trừ khi packet được recirculate qua ASIC pipeline hai lần (làm giảm băng thông đáng kể).

Các nền tảng/chip được nhắc tới có khả năng route VXLAN: Nexus 9000 (dòng EX/FX/FX2/FX3), chip Broadcom Trident 2+/3/4, Tomahawk, và Jericho. Về kinh nghiệm thực tế: switch có tốc độ 25Gbps hoặc 100Gbps trở lên gần như chắc chắn route được VXLAN; nếu switch chỉ ở mức 10Gbps hoặc 40Gbps, nên kiểm tra kỹ datasheet trước khi giả định nó hỗ trợ.

9. Populate route trong Layer 3 VNI & Type 2 Sequence Number​

Thay vì "flood and learn" như layer 2 truyền thống, EVPN dùng cơ chế có thể gọi là "flood and route" hoặc "flood and announce".

Khi một host mới kết nối vào switch và được học tại local, switch sinh ra một EVPN Type 2 route chứa cả IP lẫn MAC address của host đó (ví dụ IP 10.1.1.11, MAC 00:00:00:00:00:11), cùng với một Sequence Number.

Sequence Number tồn tại để phục vụ đúng một tình huống: vMotion. Khi host di chuyển sang một leaf khác, leaf mới sẽ generate lại route (cùng MAC/IP) nhưng tăng Sequence Number lên — nhờ đó các thiết bị khác trong fabric biết đây là bản cập nhật vị trí mới (host vừa di chuyển), chứ không phải một xung đột/duplicate cần cảnh báo.

Cơ chế này có quy tắc xử lý cụ thể (RFC 7432 §15.2 — MAC Mobility Extended Community): lần đầu một MAC được advertise, route đi kèm không có MAC Mobility extended community (ngầm hiểu sequence = 0). Khi có tranh chấp — hai leaf cùng advertise một MAC — thiết bị nhận luôn chọn route có Sequence Number cao hơn; nếu bằng nhau mới xét tiếp tiêu chí phụ. Quan trọng hơn: nếu một MAC "di chuyển" quá nhanh — mặc định ngưỡng là 5 lần trong 180 giây — thiết bị sẽ kết luận đây không phải vMotion thật, mà là tình huống duplicate MAC (ví dụ hai host bị cấu hình trùng MAC, hoặc có loop ở đâu đó khiến MAC "nhảy" liên tục), và sẽ dừng cập nhật/dấy cảnh báo thay vì tiếp tục di chuyển MAC đó qua lại vô hạn.

Một chi tiết dễ bị đơn giản hóa quá mức: route Type 2 này thực chất mang theo hai Route Target cùng lúc, không phải một. Một RT khớp với Layer 2 VNI/VLAN cục bộ (để các leaf khác đang cùng VLAN đó cài MAC vào MAC-VRF), RT còn lại khớp với Layer 3 VNI của tenant (để mọi leaf trong cùng tenant VRF — kể cả leaf không host VLAN 101 — vẫn cài được host route /32 vào IP-VRF của mình, đúng như đã nói ở Mục 7). Route còn kèm một thuộc tính riêng gọi là EVPN Router's MAC extended community, mang theo MAC vật lý thật của VTEP nguồn — nhờ đó leaf nhận biết chính xác MAC nào cần dùng để đóng gói lại traffic khi route (chứ không bridge) traffic đó ở data plane. Đây chính là cơ chế kỹ thuật đứng sau việc "một route tách vào hai forwarding space" được mô tả ngay dưới đây.

Giá trị VNI nằm trong khoảng từ 1 đến 16.777.215 (2²⁴−1, vì VNI là một trường 24-bit theo RFC 7348) — con số này được thiết kế đủ lớn để không bao giờ cạn kiệt dù mạng có scale lớn tới đâu.

Từ một Type 2 route (chứa cả MAC + IP), thông tin được tách và cài đặt vào hai forwarding space khác nhau trên thiết bị nhận:

  • Phần host route (IP /32) được cài vào Layer 3 VNI (IP VRF).
  • Phần MAC route được cài vào Layer 2 VNI (MAC VRF).

Nếu có nhiều tenant, mỗi tenant có Layer 3 VNI/IP VRF riêng để route giữa các layer 2 segment bên trong tenant đó — các forwarding space này không cấu hình y hệt VRF truyền thống trên switch, mà VLAN được đối xử như một MAC VRF, còn IP VRF là một forwarding space riêng ở tầng layer 3.

10. Tự học EVPN & lời khuyên labbing​

Loạt bài này dừng ở mức nền tảng: hiểu cách các loại VRF hoạt động, cách MAC/IP được học và forward. Bước tiếp theo tự nhiên là phần sau, nơi các route type (Type 1, 2, 3, 5) và cơ chế học MAC/IP được trình bày chi tiết hơn nhiều so với những gì đã tóm lược ở đây. Xa hơn nữa là troubleshooting — đưa một mạng không hoạt động về trạng thái hoạt động được, đòi hỏi hiểu rõ toàn bộ thành phần đang tham gia: route được announce ra sao, đi tới đâu, theo dõi được cả gói tin control-plane lẫn data-plane.

Gợi ý để tự lab: dùng Arista vEOS — tải miễn phí, không gây khó dễ, tài liệu và support đầy đủ; command line của Arista cũng khá giống Cisco nên người quen Cisco không mất nhiều công để chuyển sang. Cumulus VX cũng là một lựa chọn dễ dựng lab. Đây không phải khuyến nghị thiên vị vendor — đơn giản là con đường ít trở ngại nhất để nhanh chóng có một lab EVPN, xem được routing table, VRF, hiểu mapping và hình dung route target trông ra sao.

Về thứ tự học: nên hiểu khái niệm trước, rồi mới bắt tay vào lab — không nên lab trước khi hiểu khái niệm, vì lúc đó bạn sẽ chỉ đang gõ lệnh theo mẫu mà không biết vì sao.

Nguồn tham khảo​

Nguồn gốc: Loạt video "Intro To EVPN With Tony Bourke" (Part 1–10) — kênh Packet Pushers

  • Part 1: Welcome!
  • Part 2: Why EVPN? What's The Point?
  • Part 3: Building EVPN Topologies, Underlays & Overlays
  • Part 4: Understanding EVPN VRFs Part 1 — VRF Basics
  • Part 5: Understanding EVPN VRFs Part 2 — MAC VRF / L2VNI
  • Part 6: Stretched VLANs & Spanning Tree
  • Part 7: Understanding EVPN VRFs — IP VRF / L3VNI With Symmetric IRB
  • Part 8: EVPN Hardware Requirements
  • Part 9: Populating L3VNI Routes + Type 2 Sequence Numbers
  • Part 10: Self Learning & Labbing Recommendations

Đính chính kỹ thuật (từ fact-check RFC gốc, không có trong nội dung video gốc):

  • Giá trị VNI tối đa chính xác là 16.777.215 (2²⁴−1), không phải 16.777.214 như được nhắc trong video — VNI là một trường 24-bit theo RFC 7348 §5.
  • Symmetric IRB, mô hình được trình bày ở Mục 7, được chuẩn hoá chính thức ở RFC 9135 (10/2021) — video gốc trình bày như một design pattern chung, không trích RFC cụ thể.
  • Mục 9: video gốc mô tả Type 2 route như chỉ mang một Route Target theo Layer 2 VNI. Theo RFC 9135 và tài liệu Juniper về Symmetric IRB, route Type 2 thực chất mang hai Route Target (một cho MAC-VRF/L2 VNI, một cho IP-VRF/L3 VNI) cùng EVPN Router's MAC extended community — đây là cơ chế thực sự cho phép một route cài được vào cả hai forwarding space. Bài viết đã bổ sung chi tiết này vào Mục 9. (Juniper — Symmetric IRB with EVPN Type 2)
  • Mục 3: sơ đồ AS cho eBGP underlay (spine dùng chung AS, mỗi leaf/cặp MLAG có AS riêng) khớp với khuyến nghị chính thức tại RFC 7938 §5.2.1 ("EBGP Configuration Guidelines and Example ASN Scheme") — RFC quy định rõ: một ASN chung cho toàn bộ Tier 1 (spine), một ASN riêng cho mỗi cluster Tier 2, và một ASN riêng cho mỗi Tier 3 (ToR/leaf). Phần giải thích "vì sao" (AS_PATH loop-detection của eBGP, và lý do ECMP hoạt động mượt hơn khi spine dùng chung AS) là suy luận thêm dựa trên tính chất chuẩn của BGP (RFC 4271), không phải trích trực tiếp câu chữ của RFC 7938 hay video gốc.
  • MAC-VRF/IP-VRF định danh theo Route Target/Route Distinguisher — RFC 7432.
  • IP-VRF thực hiện lookup đối xứng trên cả MAC lẫn IP — RFC 9135, Juniper — Symmetric IRB with EVPN Type 2 Routes.
  • EVPN Type 5 (IP Prefix route) — RFC 9136.
  • Layer 3 VNI vẫn cần map vào một VLAN cục bộ (không chứa host) để gắn SVI/IRB cho VRF, vì VXLAN vốn là cơ chế Layer 2 — Cisco Community: VXLAN BGP EVPN – Why VLAN for L3 VNI?, Juniper — VXLAN and Layer 3 Logical Interfaces.
  • VNI phải giống nhau trên mọi leaf (globally significant), VLAN gán cho nó thì không — networklessons.com: VXLAN MP-BGP EVPN L3 VNI.

Tiếp theo: Route Types & Cách Học MAC/IP (đang note lại, sẽ đăng dần theo tuần)